home *** CD-ROM | disk | FTP | other *** search
ssssyyyysssstttteeeemmmm((((4444)))) ssssyyyysssstttteeeemmmm((((4444)))) NNNNAAAAMMMMEEEE system - system configuration information directory DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN This directory contains files (with the _...._ssss_mmmm suffix) that are used by the _llll_bbbb_oooo_oooo_tttt program to obtain configuration information. These files generally contain information used to determine if specified hardware exists, a list of software drivers to include in the load, and the assignment of system devices such as _r_o_o_t_d_e_v, as well as instructions for manually overriding the drivers selected by the self-configuring boot process. Each major subsystem can have its own configuration file, for example: _iiii_rrrr_iiii_xxxx_...._ssss_mmmm (base operating system configuration file), _gggg_ffff_xxxx_...._ssss_mmmm (graphics subsystem configuration file), and so forth. _llll_bbbb_oooo_oooo_tttt logically concatenates all files in the _s_y_s_t_e_m directory with the _...._ssss_mmmm suffix and processes the results. The syntax of the system files is given below. The parser for the _////_vvvv_aaaa_rrrr_////_ssss_yyyy_ssss_gggg_eeee_nnnn_////_ssss_yyyy_ssss_tttt_eeee_mmmm_////_****_...._ssss_mmmm file is case sensitive. All uppercase strings in the syntax below should be uppercase in the _////_vvvv_aaaa_rrrr_////_ssss_yyyy_ssss_gggg_eeee_nnnn_////_ssss_yyyy_ssss_tttt_eeee_mmmm_////_****_...._ssss_mmmm file as well. Nonterminal symbols are enclosed in angle brackets, , while optional arguments are enclosed in square brackets, []. Ellipses, ..., indicate optional repetition of the argument for that line. _f_n_a_m_e ::= master filename from _////_mmmm_aaaa_ssss_tttt_eeee_rrrr_...._dddd directory _f_u_n_c ::= interrupt function name _d_e_v_i_c_e_f_i_l_e :: = special device name _m_a_j_o_r ::= _n_u_m_b_e_r _m_i_n_o_r ::= _n_u_m_b_e_r _p_r_o_c ::= processor # as interpreted by _rrrr_uuuu_nnnn_oooo_nnnn(1) _n_u_m_b_e_r ::= decimal, octal or hex literal _llll_bbbb_oooo_oooo_tttt can determine if hardware exists for a given module by use of probe commands. There are three distinct probe command formats. The syntax for the first type of probe command is: _p_r_o_b_e__c_m_d ::= probe=_n_u_m_b_e_r [ probe_size=_n_u_m_b_e_r ] | _e_x_t_e_n_d_e_d__p_r_o_b_e _e_x_t_e_n_d_e_d__p_r_o_b_e ::= exprobe=_p_r_o_b_e__s_e_q_u_e_n_c_e | exprobe=(_p_r_o_b_e__s_e_q_u_e_n_c_e,_p_r_o_b_e__s_e_q_u_e_n_c_e,...) _p_r_o_b_e__s_e_q_u_e_n_c_e ::= (_s_e_q,_a_d_d_r_e_s_s,_s_i_z_e,_v_a_l_u_e,_m_a_s_k) _s_e_q ::= a sequence of 1 or more r's, rn's, or w's, indicating a read from _a_d_d_r_e_s_s or a write to _a_d_d_r_e_s_s _a_d_d_r_e_s_s ::= _n_u_m_b_e_r _s_i_z_e ::= _n_u_m_b_e_r _v_a_l_u_e ::= _n_u_m_b_e_r _m_a_s_k ::= _n_u_m_b_e_r This probe command format allows the specification of an address, and optionally, a number of bytes, to read. If a probe address is specified, the boot program attempts to read _p_r_o_b_e__s_i_z_e bytes (default 4) to determine if the hardware exists for the module. If the read succeeds, PPPPaaaaggggeeee 1111 ssssyyyysssstttteeeemmmm((((4444)))) ssssyyyysssstttteeeemmmm((((4444)))) the hardware is assumed to exist, and the module is included. The second probe command format provides the only means with which to detect peripherals on the CHALLENGE and Onyx systems (note that this format is supported on all Silicon Graphics platforms however). _p_r_o_b_e__c_m_d ::= probe_space=(_b_u_s__s_p_a_c_e,_n_u_m_b_e_r [ probe_size=_n_u_m_b_e_r ] | _e_x_t_e_n_d_e_d__p_r_o_b_e) _e_x_t_e_n_d_e_d__p_r_o_b_e ::= exprobe_space=_p_r_o_b_e__s_e_q_u_e_n_c_e | exprobe_space=(_p_r_o_b_e__s_e_q_u_e_n_c_e,_p_r_o_b_e__s_e_q_u_e_n_c_e, ...) _p_r_o_b_e__s_e_q_u_e_n_c_e ::= (_s_e_q,_b_u_s__s_p_a_c_e,_a_d_d_r_e_s_s,_s_i_z_e, _v_a_l_u_e,_m_a_s_k) _s_e_q ::= a sequence of 1 or more r's, rn's, or w's, indicating a read from _a_d_d_r_e_s_s, or a write to _a_d_d_r_e_s_s. _b_u_s__s_p_a_c_e ::= A16NP | A16S | A24NP | A24S | A32NP | A32S _a_d_d_r_e_s_s ::= _n_u_m_b_e_r _s_i_z_e ::= _n_u_m_b_e_r _v_a_l_u_e ::= _n_u_m_b_e_r _m_a_s_k ::= _n_u_m_b_e_r This extended format specifies a sequence of one or more five-tuples used to determine if the hardware exists. Each five-tuple specifies a read/write _s_e_q_u_e_n_c_e, an _a_d_d_r_e_s_s to read or write, a _s_i_z_e of up to four bytes, a _v_a_l_u_e, and a _m_a_s_k. Then, for each five-tuple, the following is performed: for each element in command do if element == 'w' then if write(address, value & mask, size) != size then failure if element == 'r' then if read(address, temp, size) != size then failure if suffix == 'n' then if temp & mask == value & mask then failure else if temp & mask != value & mask then failure The third probe command format is required to detect XIO and PCI peripherals on platforms such as Octane and Origin. _p_r_o_b_e__c_m_d ::= probe_path=_p_a_t_h_n_a_m_e The lines listed below can appear in any order. Blank lines can be inserted at any point. Comment lines must begin with an asterisk. Entries for VECTOR, EXCLUDE, and INCLUDE are cumulative. For all other entries, the last line to appear in the file is used -- any earlier entries are ignored. PPPPaaaaggggeeee 2222 ssssyyyysssstttteeeemmmm((((4444)))) ssssyyyysssstttteeeemmmm((((4444)))) There are three styles of VECTOR line. The first version is the historical version and does not work on platforms such as the CHALLENGE and Onyx series. The second VECTOR command supports the CHALLENGE and Onyx series along with bus types such as EISA. The second version is the preferred method for non XIO/PCI devices since it works across all Silicon Graphics platforms. The third version should be used for Origin, Octane, and O2 devices that use the XIO or PCI bus. VECTOR: module=_f_n_a_m_e [ intr=_f_u_n_c ] [ vector=_n_u_m_b_e_r ipl=_n_u_m_b_e_r unit=_n_u_m_b_e_r ] [ base=_n_u_m_b_e_r ] [ base2=_n_u_m_b_e_r ] [ base3=_n_u_m_b_e_r ] [ _p_r_o_b_e__c_m_d ] [ intrcpu=_n_u_m_b_e_r ] [ syscallcpu=_n_u_m_b_e_r ] Specifies hardware to conditionally load. (Note that this must be a single line.) If a probe command is specified, the boot program performs the probe sequence, as discussed above. If the sequence succeeds, the module is included. If a probe sequence is not specified, the hardware is assumed to exist. The _iiii_nnnn_tttt_rrrr function specifies the name of the module's interrupt handler. If it is not specified, the prefix defined in the module's master file (see _mmmm_aaaa_ssss_tttt_eeee_rrrr(4)) is concatenated with the string _iiii_nnnn_tttt_rrrr, and, if a routine with that name is found in the module's object (which resides in the directory _////_vvvv_aaaa_rrrr_////_ssss_yyyy_ssss_gggg_eeee_nnnn_////_bbbb_oooo_oooo_tttt), it is used as the interrupt routine. If the triplet (vector, ipl, unit, base) is specified, a VME interrupt structure is assigned, using the corresponding VME address _v_e_c_t_o_r, priority level _i_p_l, unit _u_n_i_t. If the modules' object contains a routine whose name is the concatenation of the master file prefix and _eeee_dddd_tttt_iiii_nnnn_iiii_tttt, that routine is involved once at startup and passed a pointer to an edt structure that contains the values for base, base2, base3, and a pointer to the VME interrupt structure. If intrcpu is specified, it hints to the driver the desired CPU to take interrupts on. This is only a hint and may not be honored in all cases. If syscallcpu is specified, it indicates the CPU to run non-MP driver syscalls on. This directive is always honored for non-MP drivers, and is silently ignored by MP drivers. This option should be used with caution because non-MP drivers may expect their syscalls and interrupts to run on the same CPU. VECTOR: bustype=_b_u_s_t_y_p_e module=_f_n_a_m_e adapter=_n_u_m_b_e_r ipl=_n_u_m_b_e_r [ intr=_f_u_n_c ] [ vector=_n_u_m_b_e_r ] [ ctlr=_n_u_m_b_e_r ] [ iospace=(_a_d_d_r_e_s_s-_s_p_a_c_e,_a_d_d_r_e_s_s,_s_i_z_e) ] [ iospace2=(_a_d_d_r_e_s_s-_s_p_a_c_e,_a_d_d_r_e_s_s,_s_i_z_e) ] [ iospace3=(_a_d_d_r_e_s_s-_s_p_a_c_e,_a_d_d_r_e_s_s,_s_i_z_e) ] PPPPaaaaggggeeee 3333 ssssyyyysssstttteeeemmmm((((4444)))) ssssyyyysssstttteeeemmmm((((4444)))) [ _p_r_o_b_e__c_m_d ] Specifies hardware to conditionally load. (Note that this must be a single line.) If a probe command is specified, the boot program performs the probe sequence, as discussed above. If the sequence succeeds, the module is included. If a probe sequence is not specified, the hardware is assumed to exist. The bustype specifies the type of bus on which the device is connected. This is VME for a VME bus. The adapter specifies to which bus of type bustype the device is connected. If adapter is set to _****, the system looks at each bus of type bustype to find the device. The _iiii_nnnn_tttt_rrrr function specifies the name of the module's interrupt handler. If it is not specified, the prefix defined in the module's master file (see _mmmm_aaaa_ssss_tttt_eeee_rrrr(4)) is concatenated with the string _iiii_nnnn_tttt_rrrr and if a routine with that name is found in the module's object (which resides in the directory _////_vvvv_aaaa_rrrr_////_ssss_yyyy_ssss_gggg_eeee_nnnn_////_bbbb_oooo_oooo_tttt), it is used as the interrupt routine. If the vector is not specified, it is assumed to be programmable. The ctlr field is used to pass a value into the driver that is specific to the device. This can be used to identify which device is present when there are multiple VECTOR lines for a particular device. If the modules' object contains a routine whose name is the concatenation of the master file prefix and _eeee_dddd_tttt_iiii_nnnn_iiii_tttt, that routine is involved once at startup and passed a pointer to an edt structure that contains the values for iospace, iospace2, iospace3, and a pointer to the bus info structure. VECTOR: module=_f_n_a_m_e probe_path=_p_a_t_h_n_a_m_e Specifies hardware to conditionally load (note that this must be a single line). When a device with a vendor ID and device ID is found on the system, the XIO/PCI infrastructure will add a node in the hardware graph, accessible via the format /_h_w/._i_d/{_p_c_i,_x_i_o}/[_v_e_n_d_o_r_i_d][_d_e_v_i_c_e_i_d]. For example, a PCI token ring card might be described by _////_hhhh_wwww_////_...._iiii_dddd_////_pppp_cccc_iiii_////_1111_0000_BBBB_6666_0000_0000_0000_2222 (note the id is specified in hexadecimal with capital letters). When _llll_bbbb_oooo_oooo_tttt configures the system, if _p_a_t_h_n_a_m_e exists then the driver specified by _f_n_a_m_e will be loaded. EXCLUDE: [ _s_t_r_i_n_g ] ... Specifies drivers to exclude from the load even if the device is found via VECTOR information. PPPPaaaaggggeeee 4444 ssssyyyysssstttteeeemmmm((((4444)))) ssssyyyysssstttteeeemmmm((((4444)))) INCLUDE: [ _s_t_r_i_n_g[(_n_u_m_b_e_r)] ] ... Specifies software drivers or loadable modules to be included in the load. This is necessary to include the drivers for software devices. The optional _n_u_m_b_e_r (parenthesis required) specifies the number of devices to be controlled by the driver (defaults to 1). This number corresponds to the builtin variable ##_c which can be referred to by expressions in part two of the _////_vvvv_aaaa_rrrr_////_ssss_yyyy_ssss_gggg_eeee_nnnn_////_mmmm_aaaa_ssss_tttt_eeee_rrrr file. ROOTDEV: _d_e_v_i_c_e_f_i_l_e Identifies the device containing the root filesystem. SWAPDEV: _d_e_v_i_c_e_f_i_l_e _n_u_m_b_e_r _n_u_m_b_e_r Identifies the device to be used as swap space, the block number the swap space starts at, and the number of swap blocks available. DUMPDEV: _d_e_v_i_c_e_f_i_l_e Identifies the device to be used for kernel dumps. IPL: _I_R_Q _l_e_v_e_l _p_r_o_c Send VME interrupt at _I_R_Q _l_e_v_e_l to _p_r_o_c. If _p_r_o_c does not exist at run time, the kernel defaults to use processor 0. USE: [ _s_t_r_i_n_g[(_n_u_m_b_e_r)] [ _e_x_t_e_n_d_e_d__p_r_o_b_e ] ] ... If the driver is present, it is the same as INCLUDE. Behaves like EXCLUDE if the module or driver is not present in _////_vvvv_aaaa_rrrr_////_ssss_yyyy_ssss_gggg_eeee_nnnn_////_bbbb_oooo_oooo_tttt. KERNEL: [ _s_t_r_i_n_g ] ... Specifies the module containing the heart of the operating system. It must be present in the system file. NOINTR: _p_r_o_c ... In Origin, Onyx2, OCTANE, CHALLENGE and Onyx systems, NOINTR provides a way to prevent processor(s) from receiving any interrupt other than the VME IRQ levels defined using IPL directive. This can be used for marking a processor for real time purpose. CPU 0 although should not be restricted from receiving interrupts. This directive is ignored on all other platforms. LINKMODULES: _1|_0 If set to 1, this option causes _llll_bbbb_oooo_oooo_tttt to ignore the _dddd option in all master files and link all necessary modules into the kernel. PPPPaaaaggggeeee 5555 ssssyyyysssstttteeeemmmm((((4444)))) ssssyyyysssstttteeeemmmm((((4444)))) CC LD The names of the compiler and linker used to build the kernel. If absent, they default to _cccc_cccc and _llll_dddd, respectively. CCOPTS LDOPTS Option strings given to _cccc_cccc(1) and _llll_dddd(1) respectively, to compile the _mmmm_aaaa_ssss_tttt_eeee_rrrr_...._cccc file and link the operating system. TUNE-TAG: _s_t_r_i_n_g ... Sets a set of tags to be used to qualify the various tunable parameters for inclusion. If a tunable parameter has no tag (see _mmmm_tttt_uuuu_nnnn_eeee(4)), it is always included. If a tunable parameter has a tag, it is included only if the tag matches one of the tags specified by this parameter or via the _----_OOOO option to _llll_bbbb_oooo_oooo_tttt. Tags can be used to permit a single set of _mmmm_tttt_uuuu_nnnn_eeee and _ssss_tttt_uuuu_nnnn_eeee files to represent many different configurations. DEVICE_ADMIN: _h_w_g_r_a_p_h-_d_e_v_i_c_e-_n_a_m_e _v_a_r_i_a_b_l_e-_n_a_m_e=_v_a_l_u_e Associates information (value) with the specified device and variable name for later interpretation by a device driver or other system software. This allows for a single mechanism that device drivers may use to establish arbitrary "contracts" with the administrator. The particular variable names used by a driver and the interpretation of their values are described in that device driver's documentation. DRIVER_ADMIN: _d_e_v_i_c_e-_d_r_i_v_e_r-_n_a_m_e _v_a_r_i_a_b_l_e-_n_a_m_e=_v_a_l_u_e Works just like DEVICE_ADMIN, but for device drivers rather than for instances of devices. Interpretation of variable names and values is defined by the driver and described in device driver documentation. FFFFIIIILLLLEEEESSSS /var/sysgen/system/*.sm /usr/include/sys/edt.h SSSSEEEEEEEE AAAALLLLSSSSOOOO lboot(1M), master(4), mtune(4), stune(4). PPPPaaaaggggeeee 6666 
